我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。
我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。
前面四篇，我分別從需求訪談、流程決策、人工判斷與使用者測試，整理這次參與 ERP 導入時看到的一些狀況。回過頭看這過程，雖然 EPR 顧問多數是教學 ERP 功能，實際花掉很多時間的事情，是導入方逐步定義出 SOP。
顧問會介紹請購怎麼轉採購、工單怎麼建立、BOM 怎麼展開、替代料怎麼設定，這些都是導入 ERP 一定會談到的功能。但只要深入營運現場的流程，很快就會遇到尚未標準化的流程。導入方說所有採購都要先請購，後面又出現委外檢驗或特殊類別的例外；系統可以把不同訂單的需求彙總之後採購，也可以保留一對一的關係，但導入方當時自己也還沒有決定未來要採用哪一種方式。
到了生產流程，系統本身有自然替代的機制，可以按照設定與庫存帶入替代料，導入方最後仍然選擇讓生管或物控人工判斷，再到工單上調整實際用料。 後面真的讓使用者接觸系統之後，原本會議裡已經討論完成的流程，又可能因為實際單據、操作頻率或新的例外重新被打開。
在這個導入過程，原本仰賴默契、慣例、特定員工裡的規則會被提出檢視。只要系統需要設定流程、權限、欄位與參數，很多過去可以靠經驗補掉的地方，就開始需要比較明確的答案。
第一篇談需求訪談時，課題是不能再把「我們都是這樣做」直接視為一條完整規則。使用者描述的通常是自己最熟悉的正常流程，但真正要放進系統之前，還需要確認適用範圍、例外，以及換成另一種情境之後這條規則是不是依然成立。
第二篇是另一種情況。有些問題繼續訪談也不會得到答案，因為公司本身還沒有決定未來要怎麼做。像訂單需求到底應該逐單處理，還是依料號彙總，系統兩種方式都能支援，現場也理解兩種方式的差異，最後仍然只能回答「還不確定未來的方式會怎樣」。這時候需要處理的是「有開放的流程尚未決議」，要注意現場參與者可能沒有權限決定，也需要轉交議題給真正能做決定的主管或老闆。
第三篇再深入流程細節。即使一個流程有特定角色負責，實際執行時仍然常看到「人工判斷」、「看情況」或「寫在備註」這類做法。這些模糊有些是還沒有整理完成的判斷規則，有些來自 ERP 功能本身的限制，也有一些是企業刻意留下來的彈性。像一些細微的原料規格差異，如果全部拆成不同料號，增加的料號基本資料複雜度可能比得到的管理價值還高，公司最後保留同一個料號，把特殊要求寫在備註，再交給批備料人員判斷，也可能是合理的取捨。
第四篇則把前面的判斷重新送回現場。會議裡講得通、大家也點頭的流程，真正讓使用者自己打開系統操作之後，還是可能看到缺掉的條件。某個資訊在那個時間點其實還拿不到、某個角色根本不會進到這個畫面，或者原本看起來只多一步的操作，每天做二十次之後變成很明顯的負擔。這些問題很難只靠流程圖推論，不過用很小的範圍提早測試，再根據結果往前修正，能夠儘早修正問題。
上述的狀況分開看都只是導入過程中的小問題，但是放在一起之後，我整理出 FDE 的五項工作原則。
Observe 的工作，是先理解現場實際怎麼運作。除了既有 SOP，也要看真正使用的單據、舊系統、Excel、備註，以及工作怎麼從一個角色交到下一個角色。尤其是出現例外時，大家最後找誰、靠什麼資訊解掉問題，往往比正常流程更能看出真正的營運方式。
Clarify 則是把觀察到的事情逐漸整理成可以討論的規則。「通常都這樣」、「這個一定要」、「有時候會例外」還不夠，需要繼續確認適用範圍、條件、角色與例外，並區分哪些是正式制度，哪些只是長期累積的工作習慣。
等到現況已經看得夠清楚，卻發現公司自己沒有答案，就進到 Decide。這時候要處理的事情是把真正需要決定的問題說清楚，整理目前有哪些可行選項、每個選項會影響哪些人與流程，再找到真正有權限承擔這個 Decision 的人。FDE 不一定是最後下決策的人，但不能讓這些未決議題隨著會議結束就消失。
Encode 才開始處理系統應該承接多少。前面的 Decision 可以變成 workflow、權限、Master Data、系統 constraint，也可以進一步變成自動化規則。有些情況適合讓系統直接判斷，有些只適合讓系統縮小選項或準備資訊，再交給人確認，也有一些低頻且高度依賴情境的問題，保留人工判斷反而比較合理。
Verify 最後再把這些設計交回真實使用者。測試的目的除了確認功能能不能跑，也要確認前面對流程、Decision 與使用情境的理解是不是成立。我比較傾向在範圍還很小的時候就開始做這件事，找適合的使用者，挑一小段流程，拿接近真實工作的案例讓他自己走一次。真的操作過之後，前面的假設才會開始變得比較可信。
如果只把這五層寫成 Observe、Clarify、Decide、Encode、Verify，很容易看起來像一套按照順序完成的導入程序，但我實際看到的情況比較像不斷來回。
Verify 的時候發現新的例外，可能重新回到 Clarify；兩個部門真的開始操作之後，才發現原本以為已經有共識的流程其實理解不同，就需要重新 Decide；原本希望完全自動化的規則，在整理 Decision Table 之後發現例外太多，也可能重新調整 Encode 的範圍。
甚至 Observe 也不會只發生在專案最開始。系統慢慢進到現場之後，工作方式本身可能跟著改變，又會出現新的行為、新的例外與新的問題。
所以我目前比較習慣把範圍縮小一點，把其中一段工作從 Observe 一路帶到 Verify，確認方向成立之後再繼續往外擴。這和前一篇提到的小範圍 Pilot 很接近，也比較符合我實際參與系統導入時的工作節奏。
ERP 顧問很清楚自己的產品可以怎麼做。採購可以走哪些流程、參數怎麼設定、料號與 BOM 怎麼維護、工單和庫存可以怎麼串，這些知識對導入非常重要。當顧問把 A、B 幾種系統選項攤開來，甚至用系統既有限制要求導入方做出選擇，有時候反而可以讓原本沒有被定義的流程更快浮現。
導入方掌握的是另外一種知識。他們知道每天訂單怎麼進來、哪些客戶比較特殊、缺料時現場怎麼處理，以及有問題時大家通常找誰。這些知識很多沒有完整寫在 SOP 裡，但是真正讓公司能夠運作的基礎。
我目前理解的 FDE，比較像站在這兩類資訊中間，把「系統可以怎麼做」和「現場現在怎麼做」，逐漸整理成「公司未來決定怎麼運作」。
這也是為什麼 FDE 不需要比 ERP 顧問更懂每一個 ERP 模組，也很難只靠需求文件完成工作。很多真正影響導入的問題，都是在看過系統、看過現場、理解兩邊限制之後，才有辦法被定義出來。
ERP 導入完成之後，最直接留下來的當然是一套可以使用的系統。裡面有新的流程、權限、料號、BOM、工單、庫存與報表，這些也是專案原本就需要交付的東西。
原本大家都知道的工作方式，經過導入之後，開始能夠區分哪些是真正的公司規則，哪些只是過去形成的習慣；哪些例外值得保留，哪些可以趁新系統上線重新收斂；哪些判斷必須由特定角色承擔，哪些人工判斷有機會整理成規則，又有哪些模糊度刻意留給人處理會比較合理。
這些內容很多是 domain know-how，也是公司的隱性知識，雖然不一定全部會出現在 ERP 畫面裡，但下一次公司要做 AI、自動化、資料整合或另一套系統時，都一定會遇到。
有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！
iThome鐵人賽
看影片追技術